<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
<head>
<!-- Copyright 1997 The Open Group, All Rights Reserved -->
<title>Realtime</title>
</head><body bgcolor=white>
<center>
<font size=2>
The Single UNIX &reg; Specification, Version 2<br>
Copyright &copy; 1997 The Open Group

</font></center><hr size=2 noshade><blockquote>
<center>
<h3><a name = "tag_000_008">&nbsp;</a>Realtime</h3>
</center>
<xref type="2" name="realtime"></xref>
This section defines system interfaces to support the source
portability of applications with realtime requirements.
<p>
The definition of
<i>realtime</i>
used in defining the scope of XSI provisions is:
<div>
<dl compact><dt> <dd>
Realtime in operating systems: the ability of the operating system
to provide a required level of service in a bounded response time.
</dl>
</div>
<p>
The key elements of defining the scope are:
<ol>
<p>
<li>
defining a sufficient set of functionality to cover a significant part
of the realtime application program domain, and
<p>
<li>
defining sufficient performance constraints
and performance-related functions to allow a realtime application
to achieve deterministic response from the system.
<p>
</ol>
<p>
Specifically within the scope, it is required to define interfaces
that do not preclude high-performance implementations on
traditional uniprocessor realtime systems.
<p>
Wherever possible, the requirements of other application environments are
included in this interface definition.
It is beyond the scope of these interfaces to support networking or
multiprocessor functionality.
<p>
The specific functional areas included in this section and their scope
include:
<ul>
<p>
<li>
<i>Semaphores</i>:
A minimum synchronisation primitive to serve as a basis
for more complex synchronisation mechanisms
to be defined by the application program.
<p>
<li>
<i>Process memory locking</i>:
A performance improvement facility to bind application programs
into the high-performance random access memory
of a computer system.
This avoids potential latencies introduced
by the operating system in storing
parts of a program that were not recently referenced
on secondary memory devices.
<p>
<li>
<i>Memory mapped files</i> and
<i>shared memory objects</i>: A performance improvement facility to allow for
programs to access files as part of the address space and
for separate application programs to have portions of their address
space commonly accessible.
<p>
<li>
<i>Priority scheduling</i>:
A performance and determinism improvement facility to allow applications
to determine the order in which threads that are ready to run
are granted access to processor resources.
<p>
<li>
<i>Realtime signal extension</i>:
A determinism improvement facility that augments the BASE signals mechanism
to enable asynchronous signal notifications to an
application to be queued without impacting compatibility with the existing
signals interface.
<p>
<li>
<i>Timers</i>:
A functionality and determinism improvement facility to increase the
resolution and capabilities of the time-base interface.
<p>
<li>
<i>POSIX Interprocess communication</i>:
A functionality enhancement to add a high-performance,
deterministic interprocess communication facility for local communication.
Network transparency is beyond the scope of this interface.
<p>
<li>
<i>Synchronised input and output</i>:
A determinism and robustness improvement mechanism
to enhance the data input and output mechanisms,
so that an application can insure that the data being manipulated
is physically present on secondary mass storage devices.
<p>
<li>
<i>Asynchronous input and output</i>:
A functionality enhancement to allow an application process
to queue data input and output commands with asynchronous
notification of completion.
This facility includes in its scope
the requirements of supercomputer applications.
<p>
</ul>
<p>
All the interfaces defined in the Realtime Feature Group will be
portable, although some of the numeric parameters used by an
implementation may have hardware dependencies.
<h4><a name = "tag_000_008_001">&nbsp;</a>Signal Generation and Delivery</h4>
<p>
Some signal-generating functions, such as
high-resolution timer expiration,
asynchronous I/O completion, interprocess message arrival, and the
<i><a href="sigqueue.html">sigqueue()</a></i>
function, support the specification of an application-defined value,
either explicitly as a parameter to the function or in a
<b>sigevent</b>
structure parameter.
The
<b>sigevent</b>
structure is defined in
<i><a href="signal.h.html">&lt;signal.h&gt;</a></i>
and contains at least the following members:
<p><table  bordercolor=#000000 border=1 align=center><tr valign=top><th align=center><b>Member Type</b>
<th align=center><b>Member Name</b>
<th align=center><b>Description</b>
<tr valign=top><td align=left>int
<td align=left>sigev_notify
<td align=left>Notification type
<tr valign=top><td align=left>int
<td align=left>sigev_signo
<td align=left>Signal number
<tr valign=top><td align=left>union sigval
<td align=left>sigev_value
<td align=left>Signal value
<tr valign=top><td align=left>void(*)(unsigned sigval)
<td align=left>sigev_notify_function
<td align=left>Notification
<tr valign=top><td align=left>(pthread_attr_t*)
<td align=left>sigev_notify_attributes
<td align=left>Notification attributes
</table>
<p>
The
<i>sigev_notify</i>
member specifies the notification mechanism to use
when an asynchronous event occurs.
This document defines the following values for the
<i>sigev_notify</i>
member:
<dl compact>

<dt>SIGEV_NONE<dd>
No asynchronous notification will be delivered
when the event of interest occurs.

<dt>SIGEV_SIGNAL<dd>
A queued signal, with an application-defined value, will be generated
when the event of interest occurs.

<dt>SIGEV_THREAD<dd>
A notification function will be called to perform notification.

</dl>
<p>
An implementation may define additional notification mechanisms.
<p>
The
<i>sigev_signo</i>
member specifies the signal to be generated.
The
<i>sigev_value</i>
member is the application-defined value
to be passed to the signal-catching function
at the time of the signal delivery as the
<i>si_value</i>
member of the
<b>siginfo_t</b>
structure.
<p>
The
<b>sigval</b>
union is defined in
<i><a href="signal.h.html">&lt;signal.h&gt;</a></i>
and contains at least the following members:
<p><table  bordercolor=#000000 border=1 align=center><tr valign=top><th align=center><b>Member Type</b>
<th align=center><b>Member Name</b>
<th align=center><b>Description</b>
<tr valign=top><td align=left>int
<td align=left>sival_int
<td align=left>Integer signal value
<tr valign=top><td align=left>void *
<td align=left>sival_ptr
<td align=left>Pointer signal value
</table>
The
<i>sival_int</i>
member is used when the application-defined value is of type
<b>int</b>;
the
<i>sival_ptr</i>
member is used when the application-defined value is a pointer.
<p>
When a signal is generated by the
<i><a href="sigqueue.html">sigqueue()</a></i>
function
or any signal-generating function that supports the specification
of an application-defined value,
the signal is marked pending and, if the SA_SIGINFO
flag is set for that signal, the signal is queued to the process
along with the application-specified signal value.
Multiple occurrences of signals so generated are queued in FIFO order.
It is unspecified whether signals so generated are queued when the
SA_SIGINFO flag is not set for that signal.
<p>
Signals generated by the
<i><a href="kill.html">kill()</a></i>
function or other events that cause signals to occur,
such as detection of hardware faults,
<i><a href="alarm.html">alarm()</a></i>
timer expiration, or terminal activity,
and for which the implementation does not support queuing,
have no effect on signals already queued for the same signal number.
<p>
When multiple unblocked signals, all in the range
SIGRTMIN to SIGRTMAX, are pending,
the behaviour is as if
the implementation delivers the pending unblocked signal
with the lowest signal number within that range.
No other ordering of signal delivery is specified.
<p>
If, when a pending signal is delivered,
there are additional signals queued to that signal number,
the signal remains pending.
Otherwise, the pending indication is reset.
<h4><a name = "tag_000_008_002">&nbsp;</a>Asynchronous I/O</h4>
An asynchronous I/O control block structure
<b>aiocb</b>
is used in many asynchronous I/O function interfaces.
It is defined in
<i><a href="aio.h.html">&lt;aio.h&gt;</a></i>
and has at least the following members:
<p><table  bordercolor=#000000 border=1 align=center><tr valign=top><th align=center><b>Member Type</b>
<th align=center><b>Member Name</b>
<th align=center><b>Description</b>
<tr valign=top><td align=left>int
<td align=left>aio_fildes
<td align=left>File descriptor
<tr valign=top><td align=left>off_t
<td align=left>aio_offset
<td align=left>File offset
<tr valign=top><td align=left>volatile void*
<td align=left>aio_buf
<td align=left>Location of buffer
<tr valign=top><td align=left>size_t
<td align=left>aio_nbytes
<td align=left>Length of transfer
<tr valign=top><td align=left>int
<td align=left>aio_reqprio
<td align=left>Request priority offset
<tr valign=top><td align=left>struct sigevent
<td align=left>aio_sigevent
<td align=left>Signal number and value
<tr valign=top><td align=left>int
<td align=left>aio_lio_opcode
<td align=left>Operation to be performed
</table>
<p>
The
<i>aio_fildes</i>
element is the file descriptor on which the asynchronous operation is
to be performed.
<p>
If O_APPEND is not set for the file descriptor
<i>aio_fildes</i>,
and if
<i>aio_fildes</i>
is associated with a device that is capable of seeking,
then the requested operation takes place at the absolute position in
the file as given by
<i>aio_offset</i>,
as if
<i><a href="lseek.html">lseek()</a></i>
were called immediately prior to the operation with an
<i>offset</i>
argument equal to
<i>aio_offset</i>
and a
<i>whence</i>
argument equal to
SEEK_SET .
If O_APPEND is set for the file descriptor, or if
<i>aio_fildes</i>
is associated with a device that is incapable of seeking,
write operations append to the file in the same order as the calls
were made,
with the following exception.
Under implementation-dependent circumstances,
such as operation on a multiprocessor or
when requests of differing priorities are submitted at the same time,
the ordering restriction may be relaxed.
After a successful call to enqueue an asynchronous I/O operation,
the value of the file offset for the file is unspecified.
The
<i>aio_nbytes</i>
and
<i>aio_buf</i>
elements are the same as the
<i>nbyte</i>
and
<i>buf</i>
arguments defined by
<i><a href="read.html">read()</a></i>
and
<i><a href="write.html">write()</a></i>
respectively.
<p>
If _POSIX_PRIORITIZED_IO and _POSIX_PRIORITY_SCHEDULING
are defined, then asynchronous I/O is queued in priority order,
with the priority of each asynchronous operation based on the
current scheduling priority of the calling process.
The
<i>aio_reqprio</i>
member can be used to lower (but not raise)
the asynchronous I/O operation priority
and will be within the range zero through
AIO_PRIO_DELTA_MAX, inclusive.
The order of processing of requests
submitted by processes whose schedulers are not
SCHED_FIFO or SCHED_RR is unspecified.
The priority of an asynchronous request is computed as
(process scheduling priority) minus
<i>aio_reqprio</i>.
The priority assigned to each asynchronous I/O request is an
indication
of the desired order of execution of the request
relative to other asynchronous I/O requests for this file.
If _POSIX_PRIORITIZED_IO
is defined, requests issued with the same priority to a character
special file will be processed by the underlying device in FIFO
order;
the order of processing of requests of the same priority issued to
files
that are not character special files is unspecified.
Numerically higher priority values indicate requests of higher
priority.
The value of
<i>aio_reqprio</i>
has no effect on process scheduling priority.
When prioritized asynchronous I/O requests to the same file
are blocked waiting for a resource required for that I/O operation,
the higher-priority I/O requests will be granted the resource
before lower-priority I/O requests are granted the resource.
The relative priority of asynchronous I/O and synchronous I/O
is implementation-dependent.
If _POSIX_PRIORITIZED_IO is defined,
the implementation defines for which files
I/O prioritization is supported.
<p>
The
<i>aio_sigevent</i>
determines how the calling process will be notified upon I/O completion
as specified in
<xref href=siggendel><a href="sigaction.html#tag_000_008_620_001">
Signal Generation and Delivery
</a></xref>.
If
<i>aio_sigevent.sigev_notify</i>
is SIGEV_NONE, then no signal will be posted upon I/O completion,
but the error status for the operation and the return status for the operation
will be set appropriately.
<p>
The
<i>aio_lio_opcode</i>
field is used only by the
<i><a href="lio_listio.html">lio_listio()</a></i>
call.
The
<i><a href="lio_listio.html">lio_listio()</a></i>
call allows multiple asynchronous I/O operations to be submitted
at a single time.
The function takes as an argument an array of pointers to
<b>aiocb</b>
structures.
Each
<b>aiocb</b>
structure indicates the operation to be performed (read or write)
via the
<i>aio_lio_opcode</i>
field.
<p>
The address of the
<b>aiocb</b>
structure is used as a
handle for retrieving the error status and return status
of the asynchronous operation while it is in progress.
<p>
The
<b>aiocb</b>
structure and the data buffers
associated with the asynchronous I/O operation are being used
by the system for asynchronous I/O while, and only while,
the error status of the asynchronous operation
is equal to EINPROGRESS.
Applications must not modify the
<b>aiocb</b>
structure while the structure is being used by the system for
asynchronous I/O.
<p>
The return status of the asynchronous operation
is the number of bytes transferred by the I/O operation.
If the error status is set to indicate an error completion,
then the return status is set to the return value that the
corresponding
<i><a href="read.html">read()</a></i>,
<i><a href="write.html">write()</a></i>,
or
<i><a href="fsync.html">fsync()</a></i>
call would have returned.
When the error status is not equal to EINPROGRESS,
the return status
reflects the return status of the corresponding synchronous operation.
<h4><a name = "tag_000_008_003">&nbsp;</a>Memory Management</h4>
Range memory locking and memory mapping operations are defined in
terms of pages.
Implementations may restrict the size and alignment
of range lockings and mappings to be on
page-size boundaries.
The page size, in bytes, is the value of the configurable system
variable {PAGESIZE}.
If an implementation has no restrictions on size or alignment,
it may specify a 1 byte page size.
<p>
Memory locking guarantees the residence of portions of the address
space.  It is implementation-dependent
whether locking memory guarantees fixed translation between virtual
addresses (as seen by the process) and physical addresses.
Per-process memory locks are not inherited across a
<i><a href="fork.html">fork()</a></i>,
and all memory locks owned by a process are unlocked upon
<i>exec</i>
or process termination.
Unmapping of an address range removes any memory locks
established on that address range by this process.
<p>
Memory Mapped Files provide a mechanism that allows a
process to access files
by directly incorporating file data into its address space.
Once a file is mapped into a process address space,
the data can be manipulated as memory.
If more than one process maps a file, its contents are shared among them.
If the mappings allow shared write access
then data written into the memory object
through the address space of one process appears
in the address spaces of all processes
that similarly map the same portion of the memory object.
<p>
Shared memory objects are named regions of storage
that may be independent of the file system and can be mapped into
the address space of one or more processes to allow them to share the
associated memory.
<p>
An
<i><a href="unlink.html">unlink()</a></i>
of a file
or
<i><a href="shm_unlink.html">shm_unlink()</a></i>
of a shared memory object,
while causing the removal of the name,
does not unmap any mappings established for the object.
Once the name has been removed,
the contents of the memory object are preserved as long as it is
referenced.
The memory object remains referenced
as long as a process has the memory object open
or has some area of the memory object mapped.
<p>
Mapping may be restricted to disallow some types of access.
References to whole pages within the mapping
but beyond the current length of an object result in a
SIGBUS signal.
SIGBUS is used in this context to indicate an error using the object.
The size of the object is unaffected by access beyond the end of the
object.
Write attempts to memory that was mapped without write access,
or any access to memory mapped PROT_NONE,
results in a SIGSEGV signal.
SIGSEGV is used in this context to indicate a mapping error.
References to unmapped addresses result in a SIGSEGV signal.
<h4><a name = "tag_000_008_004">&nbsp;</a>Scheduling Policies</h4>
<p>
The scheduling semantics described in this specification are defined
in terms of a conceptual model that contains a set of thread lists.
No implementation structures are necessarily implied
by the use of this conceptual model.
It is assumed that no time elapses during operations
described using this model,
and therefore no simultaneous operations are possible.
This model discusses only processor scheduling for runnable threads,
but it should be noted that greatly enhanced predictability
of realtime applications will result
if the sequencing of other resources takes
processor scheduling policy into account.
<p>
There is, conceptually, one thread list for each priority.
Any runnable thread may be on any thread list.
Multiple scheduling policies are provided.
Each non-empty thread list is ordered,
contains a head as one end of its order, and a tail as the other.
The purpose of a scheduling policy is to define the allowable operations
on this set of lists
(for example, moving threads between and within lists).
<p>
Each process is controlled
by an associated scheduling policy and priority.
These parameters may be specified by explicit application execution of the
<i><a href="sched_setscheduler.html">sched_setscheduler()</a></i>
or
<i><a href="sched_setparam.html">sched_setparam()</a></i>
functions.
<p>
Each thread is controlled by an associated scheduling policy and
priority.  These parameters may be specified by explicit application
execution of the
<i><a href="pthread_setschedparam.html">pthread_setschedparam()</a></i>
function.
<p>
Associated with each policy is a priority range.
Each policy definition specifies
the minimum priority range for that policy.
The priority ranges for each policy may or may not overlap the priority ranges
of other policies.
<p>
A conforming implementation selects the thread that is defined as
being at the head of the highest priority non-empty thread list
to become a running thread, regardless of its associated policy.
This thread is then removed from its thread list.
<p>
Three scheduling policies are specifically required.
Other implementation-dependent scheduling policies may be defined.
The following symbols are defined in the header
<i><a href="sched.h.html">&lt;sched.h&gt;</a></i>:
<div>
<p><table  bordercolor=#000000 border=1 align=center><tr valign=top><th align=center><b>Symbol</b>
<th align=center><b>Description</b>
<tr valign=top><td align=left>SCHED_FIFO
<td align=left>First in-first out (FIFO) scheduling policy.
<tr valign=top><td align=left>SCHED_RR
<td align=left>Round robin scheduling policy.
<tr valign=top><td align=left>SCHED_OTHER
<td align=left>Another scheduling policy.
</table>
</div>
<p>
The values of these symbols will be distinct.
<h5><a name = "tag_000_008_004_001">&nbsp;</a>SCHED_FIFO</h5>
Conforming implementations include a scheduling policy
called the FIFO scheduling policy.
<p>
Threads scheduled under this policy are chosen from a
thread list that is ordered by the time
its threads have been on the list without being executed;
generally, the head of the list is
the thread that has been on the list the longest time,
and the tail is the
thread that has been on the list the shortest time.
<p>
Under the SCHED_FIFO
policy, the modification of the definitional thread lists is as follows:
<ol type = 1>
<p>
<li>
When a running thread becomes a preempted thread, it becomes the head
of the thread list for its priority.
<p>
<li>
When a blocked thread becomes a runnable thread, it becomes the tail
of the thread list for its priority.
<p>
<li>
When a running thread calls the
<i><a href="sched_setscheduler.html">sched_setscheduler()</a></i>
function,
the process specified in the function call is modified to the specified policy
and the priority specified by the
<i>param</i>
argument.
<p>
<li>
When a running thread calls the
<i><a href="sched_setparam.html">sched_setparam()</a></i>
function, the priority of the process specified in the function call
is modified to the priority specified by the
<i>param</i>
argument.
<p>
<li>
When a running thread calls the
<i><a href="pthread_setschedparam.html">pthread_setschedparam()</a></i>
function, the thread specified in the function call is modified to the
specified policy and the priority specified by the
<i>param</i>
argument.
<p>
<li>
If a thread whose policy or priority has been modified is a running
thread or is runnable, it then becomes the tail of the thread list for
its new priority.
<p>
<li>
When a running thread issues the
<i><a href="sched_yield.html">sched_yield()</a></i>
function,
the thread becomes the tail of the thread list for its priority.
<p>
<li>
At no other time will the position of a thread with this scheduling policy
within the thread lists be affected.
<p>
</ol>
<p>
For this policy, valid priorities shall be within the range returned by the
function
<i><a href="sched_get_priority_max.html">sched_get_priority_max()</a></i>
and
<i><a href="sched_get_priority_min.html">sched_get_priority_min()</a></i>
when SCHED_FIFO
is provided as the parameter.
Conforming implementations provide a priority range of at least 32
priorities for this policy.
<h5><a name = "tag_000_008_004_002">&nbsp;</a>SCHED_RR</h5>
<p>
Conforming implementations include a scheduling policy called the
round robin scheduling policy.
This policy is identical to the SCHED_FIFO
policy with the additional condition that when the implementation detects that
a running thread has been executing as a running thread
for a time period of the length returned by the function
<i><a href="sched_rr_get_interval.html">sched_rr_get_interval()</a></i>
or longer,
the thread becomes the tail of its thread list
and the head of that thread list is removed and made a running thread.
<p>
The effect of this policy is to ensure that if there are
multiple SCHED_RR threads at the same priority,
one of them will not monopolise the processor.
An application should not rely only on the use of
SCHED_RR to ensure application progress among multiple threads
if the application includes threads using the
SCHED_FIFO policy at the same or higher priority levels or
SCHED_RR threads at a higher priority level.
<p>
A thread under this policy that is preempted and subsequently resumes
execution as a running thread
completes the unexpired portion of its round-robin-interval time period.
<p>
For this policy, valid priorities will be within the range
returned by the functions
<i><a href="sched_get_priority_max.html">sched_get_priority_max()</a></i>
and
<i><a href="sched_get_priority_min.html">sched_get_priority_min()</a></i>
when SCHED_RR is provided as the parameter.
Conforming implementations will provide a priority range of at least 32
priorities for this policy.
<h5><a name = "tag_000_008_004_003">&nbsp;</a>SCHED_OTHER</h5>
<p>
Conforming implementations include
one scheduling policy identified as SCHED_OTHER
(which may execute identically with either the FIFO
or round robin scheduling policy).
The effect of scheduling threads with the
SCHED_OTHER policy in a system in which other threads
are executing under SCHED_FIFO or SCHED_RR
is implementation-dependent.
<p>
This policy is defined to allow conforming applications to be able
to indicate that they no longer need a realtime scheduling policy
in a portable manner.
<p>
For threads executing under this policy,
the implementation uses only priorities within the range returned by the
functions
<i><a href="sched_get_priority_max.html">sched_get_priority_max()</a></i>
and
<i><a href="sched_get_priority_min.html">sched_get_priority_min()</a></i>
when SCHED_OTHER
is provided as the parameter.
<h4><a name = "tag_000_008_005">&nbsp;</a>Clocks and Timers</h4>
The header file
<i><a href="time.h.html">&lt;time.h&gt;</a></i>
defines the types and manifest constants used by the timing facility.
<h5><a name = "tag_000_008_005_001">&nbsp;</a>Time Value Specification Structures</h5>
<p>
Many of the timing facility functions accept or return time value
specifications.
A time value structure
<b>timespec</b>
specifies a single time value and includes at least the following members:
<p><table  bordercolor=#000000 border=1 align=center><tr valign=top><th align=center><b>Member Type</b>
<th align=center><b>Member Name</b>
<th align=center><b>Description</b>
<tr valign=top><td align=left>time_t
<td align=left>tv_sec
<td align=left>Seconds
<tr valign=top><td align=left>long
<td align=left>tv_nsec
<td align=left>Nanoseconds
</table>
<p>
The
<i>tv_nsec</i>
member is only valid if greater than or equal to zero,
and less than the number of nanoseconds in a second (1000 million).
The time interval described by this structure is
(<i>tv_sec</i> * 10'-.4m'<small>9</small>'.4m' + <i>tv_nsec</i>)
nanoseconds.
<p>
A time value structure
<b>itimerspec</b>
specifies an initial timer value and a repetition interval
for use by the per-process timer functions.
This structure includes at least the following members:
<p><table  bordercolor=#000000 border=1 align=center><tr valign=top><th align=center><b>Member Type</b>
<th align=center><b>Member Name</b>
<th align=center><b>Description</b>
<tr valign=top><td align=left>struct timespec
<td align=left>it_interval
<td align=left>Timer period
<tr valign=top><td align=left>struct timespec
<td align=left>it_value
<td align=left>Timer expiration
</table>
<p>
If the value described by
<i>it_value</i>
is non-zero, it indicates the time to or time of the next timer expiration
(for relative and absolute timer values, respectively).
If the value described by
<i>it_value</i>
is zero, the timer is disarmed.
<p>
If the value described by
<i>it_interval</i>
is non-zero, it specifies an interval to be used in reloading the timer
when it expires; that is,
a periodic timer is specified.
If the value described by
<i>it_interval</i>
is zero, the timer will be disarmed after its next expiration; that is, a
one-shot timer is specified.
<h5><a name = "tag_000_008_005_002">&nbsp;</a>Timer Event Notification Control Block</h5>
<p>
Per-process timers may be created that notify the process
of timer expirations by queuing a realtime extended signal.
The
<b>sigevent</b>
structure, defined in
<i><a href="signal.h.html">&lt;signal.h&gt;</a></i>,
is used in creating such a timer.
The
<b>sigevent</b>
structure contains the signal number and an application-specific data value
to be used when notifying
the calling process of timer expiration events.
<h5><a name = "tag_000_008_005_003">&nbsp;</a>Manifest Constants</h5>
<p>
The following constants are defined in
<i><a href="time.h.html">&lt;time.h&gt;</a></i>:
<dl compact>

<dt>CLOCK_REALTIME<dd>
The identifier for the systemwide realtime clock.

<dt>TIMER_ABSTIME<dd>
Flag indicating time is absolute
with respect to the clock associated with a timer.

</dl>
<p>
The maximum allowable resolution for the CLOCK_REALTIME
clock and all timers based on this clock, including the
<i><a href="nanosleep.html">nanosleep()</a></i>
function, is represented by {_POSIX_CLOCKRES_MIN}
and is defined as 20 ms (1/50 of a second).
Implementations may support smaller values of resolution for the
CLOCK_REALTIME clock to provide finer granularity time bases.
<p>
The minimum allowable maximum value for the CLOCK_REALTIME
clock and absolute timers based on it
is the same as that defined by the ISO C standard for the
<i>time_t</i>
type.
</blockquote><hr size=2 noshade>
<center><font size=2>
UNIX &reg; is a registered Trademark of The Open Group.<br>
Copyright &copy; 1997 The Open Group
<br> [ <a href="../index.html">Main Index</a> | <a href="../xshix.html">XSH</a> | <a href="../xcuix.html">XCU</a> | <a href="../xbdix.html">XBD</a> | <a href="../cursesix.html">XCURSES</a> | <a href="../xnsix.html">XNS</a> ]

</font></center><hr size=2 noshade>
</body></html>
